Lower gamma_correct so the LEDs dim below 28/255 - #20
Conversation
gamma_correct defaults to 2.8, and calculate_gamma_table() computes round((i/255)^gamma * 255), so indices 0 through 27 all map to 0. Below 28/255 the LEDs were driven fully off rather than dim, while the entity still reported on. 1.5 brings the first lit value down to 4/255 and keeps a perceptual curve rather than going fully linear. Set on the partitions because that is the correction that applies: light_partition.h get_view_internal() calls raw_set_color_correction() with the partition's own correction for every pixel it writes, so the parent chain's value would be inert. Version 26.8.26.4 🤖 Generated with [Claude Code](https://claude.com/claude-code)
|
Important
This repository does not receive automatic reviews because it has fewer than 10 stars. ⚙️ Run configurationConfiguration used: Organization UI Review profile: CHILL Plan: Pro Plus Run ID: Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out. Comment |
…s-gamma # Conflicts: # Integrations/ESPHome/Core.yaml
|
Closing this. It treats a symptom, and the root cause is upstream. The dead zone below 28/255 is not a dimming limit. Every gamma value bottoms out at the same place, output 1/255, which is the hardware floor for a WS2812: So lowering gamma does not produce a dimmer ornament. It only changes which slider position reaches the floor that was already reachable. The ornament at 28/255 today is already as dim as the hardware goes. What it does change is everything else. The 54 hard-coded brightness values in the config are slider-side numbers that pass through the same curve, so they all render brighter. The actual defect is in ESPHome. Once that lands, the dead zone goes away with no change to this repo at all. |
1 participant
Version: 26.8.26.4
What does this implement/fix?
Setting a zone below 28/255 turned the LEDs off completely while the entity still reported on. This was not a dimming limit, it was quantization.
gamma_correctdefaults to 2.8, andcalculate_gamma_table()computesgamma_table_[i] = round((i/255)^gamma * 255). At that exponent every index from 0 to 27 rounds to 0, so any brightness under 28/255 was written as literal off.Lowering it to 1.5 brings the first value that lights up down to 4/255 while keeping a perceptual curve rather than going fully linear:
gamma_correctSet on the six partitions rather than on
led_chain, because the partition's correction is the one that applies.light_partition.hget_view_internal()callsview.raw_set_color_correction(&this->correction_)for every pixel a partition writes, so a value on the parent chain would be inert.Expected side effect, worth checking on hardware
Every fixed brightness in the config was tuned against the 2.8 curve, so they all render brighter now:
brightness:play_song_*light showsstatusCheckandtestScriptThe status colors are the big move, from nearly invisible to clearly visible. That may be an improvement rather than a regression, but it is a visible change and it should be looked at. This PR deliberately changes only
gamma_correctso the effect is unambiguous; retuning those fixed values to preserve the old appearance can be a follow-up if the new levels are too bright.Types of changes
Checklist / Checklijst:
If user-visible functionality or configuration variables are added/modified:
esphome configpasses on both H-3.yaml and H-3D.yaml, and all six partitions carry the value in the merged config. Not yet tested on hardware.🤖 Generated with Claude Code